-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat/typedefs #36
Feat/typedefs #36
Conversation
Edit: done* |
@lostrepo thanks for this! will take a look over the weekend. 🙏 |
@lostrepo sorry - i had to push some changes up before i had a chance to review this. would you mind rebasing when you have a chance? i will get this merged over next couple days once i have had a look. 🙏 |
"lo init" doesn't modify existing files except ones generated by internal "lo type" call files generated by "lo type" can be removed (but must update binding symbols)
rebased
ideally, we should have 2 objects so real type of one returned by |
we use -std=c++17 ./v8/include/v8-local-handle.h:401:30: error: template-id not allowed for constructor in C++20
use LO_WARN environment variable if breaking fixes like that are needed for local development
…hints ts bails on intersections of complex types
few hardcoded consts still remain
replace Core.os: OS with Core.os: CurrentRuntimeGenerics['os'] later do the same for arch, engine so unreachable (lo.core[<runtime_generic>] === 'value') checks will be marked red by type checker and it'll infer correct types without us writing extra d.ts files
added
lo type <config path>
to autogenerate subset of types based on included embeds/libs/bindings (as much as possible)replaced api schema typing imports with type comments
added
optional
array to hint optional params in api definitionsreduced amount of file rewrites with
lo init
andlo type <config path>